Pre-reserve capacity for the tempTagMessages vector in commitMessages() to eliminate dynamic reallocations during message parsing. Currently, the tempTagMessages vector grows dynamically as messages are parsed, causing multiple reallocations in the hot commit path. Each reallocation involves allocating new memory, copying existing elements, and freeing old memory. This happens on every TLog commit, adding unnecessary overhead.

The PR estimates the number of messages based on total byte size and pre-reserve vector capacity:

size_t estimatedMsgCount = std::max(size_t(messages.size() / 150), size_t(10));
estimatedMsgCount = std::min(estimatedMsgCount, size_t(5000));
self->tempTagMessages.reserve(estimatedMsgCount);

• 150 bytes average message size
• Minimum reserve of 10 messages
• Cap at 5000 messages to prevent over-allocation

(note: These values are heuristics derived from typical message sizes and TLog workloads. They are not expected to require tuning in production, so they are fixed constants rather than knobs.)

This will be enabled once counters in production confirm the average message size.

A microbenchmark was written. Each tests simulate the commitMessages() parsing loop by creating realistic TagsAndMessage objects with variable sizes and pushing them into a vector. The benchmark measures three strategies: NoReserve (current implementation with dynamic growth), WithReserve (optimization using size estimation), and ExactReserve (theoretical "best case" with perfect knowledge of message count). Test scenarios cover typical TLog workloads from light (10 messages) to burst (5000 messages) loads.

100K pass 20251201-193900-dlambrig-20b1c69efc0fb7b0

Code-Reviewer Section

The general pull request guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

If this PR is made against a release-branch, please also check the following:

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)